On the Macintosh, we're all used to the simple concept of double-clicking on a document icon to open it in the proper application. The Macintosh keeps track of which documents go with which applications by type and creator codes. Thus, we tend not to think about file formats as much as people who use operating systems that lack the Mac's elegance. Nonetheless, every Mac file does have a format, and if you've ever seen the "Application not found" message, you may have wished for an easier way to determine a file's format.
Note: Various utility programs such as Apple's free ResEdit and PrairieSoft's commercial DiskTop can show you the type and creator codes that the Mac's Finder uses to link documents and applications. You can find ResEdit at:
ftp://ftp.support.apple.com/pub/apple_sw_updates/US/mac/utils/
When you start exploring, you quickly discover that most files on the Internet have filename extensions, as is standard in DOS. Unlike DOS, Unix allows long filenames, so you don't have to think of meaningless eight-character names for everything. Extensions are extremely useful on the Internet because they identify what sort of file you're looking at. On the Mac, you see a different icon or you can double-click on the file and see what program launches, but on the Internet, all you get is the filename and extension.
Unlike standard DOS usage, in which every program seems to have at least one or two extensions for its documents (.wk1, .wks, .doc, .wp, .dbf, .ndx, .idx, and other thoroughly memorable three-letter combinations), a limited set of extensions is in common use for files that Mac users care about. These extensions fall into three basic categories: those used to indicate ASCII encoding, those used to indicate compression formats, and several others used to mark certain types of text, graphics, sound, and video files.
Programs and other binary data files (files with more than just straight text in them) contain binary codes that most email programs don't understand, because email programs are designed to display only text. Binary data files even include data files such as word processor files, which contain formatting information or other nonprinting characters. Most programs enable you to save your files in a variety of formats, including text. If you don't explicitly save a file in some kind of text format, then it's probably a binary data file, although there are exceptions.
Note: The main exceptions to this are Apple's TeachText and SimpleText and Nisus Software's Nisus Writer word processor. TeachText and SimpleText can save only text files. Nisus Writer saves its files in such a way that all other programs see them as text files (the formatting lives in the file's resource fork, if you were wondering).
Computers of different types generally agree on only the first 128 characters in the ASCII character set. (ASCII stands for American Standard Code for Information Interchange.) The important fact to remember is that after those first 128 characters, which include the letters of the alphabet and numbers and punctuation, a Mac's accented letter may be a DOS machine's smiley face.
Still, people want to transfer files via email and other programs that cannot handle all the possible binary codes in a data file or application. Programmers therefore came up with several different ways of representing 8 bits of binary data in 7 bits of straight text. In other words, these conversion programs can take in a binary file such as the Alarm Clock desk accessory, for instance, and convert it into a long string of numbers, letters, and punctuation marks. Another program can take that string of text and turn it back into a functioning copy of the Alarm Clock desk accessory. I'll leave it to the philosophers to decide whether it is the same program.
Once encoded, that file can travel through almost any email gateway and be displayed in any email program, although it's worthless until you download it to the Mac and decode it. The main drawback to this sort of encoding is that you must always decode the file before you can work with it, although many programs on the Mac decode for you automatically. In addition, because you move from an 8-bit file to a 7-bit file during the encoding process, the encoded file must be larger than the original, sometimes by up to as much as 35 percent.
Now that you understand why we go through such bother, the Internet uses three main encoding formats (see table 10.1): BinHex, uuencode, and btoa (read as "b to a").
Table 10.1: ASCII Encoding Formats
Format Advantages Disadvantages
BinHex Macintosh standard Least efficient
uuencode Used by LAN email gateways Doesn't encode resource fork
btoa Most efficient Least common
BinHex is by far the most common format you see in the Macintosh world because it originated on the Mac and works best with Macintosh files. In fact, it's basically used only on Macintosh computers. You can identify most BinHex files by the .hqx extension they carry. I haven't the foggiest idea why it is .hqx instead of .bhx or something slightly more reasonable. Keep in mind that BinHex is another one of these computer words that works as a verb, too, so people say that they binhexed a file before sending it to you.
Note: There's another reason for using BinHex when working with Macintosh files. Macintosh files have two forks, a data fork and a resource fork. Most other operating systems don't understand different forks, so you need a way to combine the forks into a single file suitable for uploading to a different machine. There are two basic ways to do this, MacBinary and BinHex. MacBinary creates a binary file that combines the two forks, whereas BinHex combines them in a text file. Since text files have other advantages in terms of surviving mail gateways, people use BinHex far more often. MacBinary files must be downloaded in binary mode and usually end with a .bin extension. Most programs that can download files understand MacBinary, but if they don't you can get a stand-alone version at:
ftp://ftp.tidbits.com/pub/tidbits/tisk/util/
There are two flavors of BinHex, but they aren't interchangeable. The BinHex 4.0 format was originally created by Yves Lempereur and has been around forever. BinHex 5.0, which also came from Yves, is more recent but unfortunately causes massive confusion because it doesn't turn binary files into ASCII. Ignore BinHex 5.0 entirely, because everyone else does.
Note: BinHex 4.0 is a file format, and numerous programs can encode and decode that format. Yves wrote a program called BinHex 4.0 years ago, but it has some known bugs and should be avoided. I recommend that you use Aladdin's free StuffIt Expander for debinhexing files, especially because it can also expand various compression formats, and because it's on the ISKM disk.
Every BinHex file starts with the phrase (This file must be converted with BinHex 4.0) even if another program actually did the creating. Then comes a new line with a colon at the start, followed by many lines of ASCII gibberish. Only the last line can be a different length than the others (each line has a hard return after it), and the last character must be a colon as well (see figure 10.1). Occasionally, something happens to a BinHex file in transit and one line is shortened by a character or two or even deleted. When that happens, the file is toast.
Figure 10.1: Example of BinHex.
BinHex suffers from only two real problems other than a confusing name. It is perhaps the least efficient of the three encoding formats, which means that it wastes more space than other formats. Oh well, just because something is the standard doesn't mean it's the best. Its other real problem is that even though tools exist for debinhexing files on other platforms, they aren't common. Use uuencode if you plan to send binary files that have only a data fork (such as Microsoft Word files, for instance) to a user on another platform.
Note: Under Unix, you must use a program called mcvert to debinhex files. If you wish to encode or decode BinHex files on a PC, you can find a PC version of BinHex at:
ftp://boombox.micro.umn.edu/pub/binhex/MSDOS/binhex.exe
In the Unix world, uucode (also called uuencode) is the most common format. You can identify a uuencoded file by its .uu extension.
Although not in common usage in the Macintosh world, uucode is seen frequently enough that a number of Macintosh programs have sprung up to encode and decode this format. These include StuffIt Deluxe, UULite, and UMCP Tools, among others. You're unlikely to run across uuencoded Macintosh files frequently, mostly because uucode format ignores the resource fork of Macintosh files, making it useful for files that only have a data fork. For example, most programs store their code in the resource fork so uuencoding and then uudecoding a program renders the result totally unusable. You may run across slightly different extensions on occasion; I've also seen .uud and .uue. They're all the same thing.
Note: By default, most LAN-based email programs (such as Microsoft Mail) that have Internet gateways encode binary files sent across the Internet in uucode format, since it's the most common.
Most uuencoded files start with begin 644, followed by the filename. From that point on, they look a lot like BinHex files: rows upon rows of ASCII gibberish with each line being the same length. (Actually, these lines may not all look the same length when you're viewing them on the Mac, because Unix machines use the ASCII 10 linefeed character instead of a carriage return, which the Mac uses to end a line.)
Note: Because the number 644 is related to Unix file permissions (don't ask), other numbers are possible at the top of uuencoded files, although I see them less frequently.
All uuencoded files end with a linefeed, a space, the word end, and another linefeed (see figure 10.2).
Figure 10.2: Example of uucode.
Frankly, I don't know a lot about btoa, which stands for binary to ASCII. This format (see figure 10.3) is supported by a complementary atob convertor, which translates ASCII files back into binary. It is reportedly the most efficient of the three, so a btoa file is slightly smaller than the equivalent uuencode or BinHex file. In addition, btoa retains the multiple forks of Macintosh files, unlike uucode. Despite these seemingly major advantages, btoa doesn't appear nearly as frequently in the Unix world as uuencode, and appears rarely in the Macintosh world. As far as I know, the only program that can decode the btoa format on the Mac is StuffIt Deluxe, through one if its many translators.
Figure 10.3: Example of btoa.
Along with the various ASCII encoded formats, on the Internet you frequently see a number of file extensions that indicate the files have been compressed in some way. Almost every file available on the Internet is compressed because disk space is at a premium everywhere.
Unfortunately, because the majority of Macintosh files stored on the Internet are binhexed after being compressed, you don't see the full benefit of the compression. Nevertheless, if your original file is 200K and a compression program reduces it to 75K, you're still on the winning side even if binhexing the file increases it back up to 100K.
The folks who run the Internet file sites like two things to be true about a compression format. First, they want it to be as tight as possible, so as to save the most space. Second, they want to be sure that the files stored in that format will be accessible essentially forever. This requires the format of the compressed files to be made public; in theory, any competent programmer can write a program to expand those files should the company go out of business or otherwise disappear.
This second desire has caused some trouble over the years because the compression market is hotly contested. Companies seldom want to put their proprietary compression algorithms (the rules by which a file is compressed) into the public domain, where their competitors can copy them. For a while there was a project on the Internet to create a public format based on some other public compression formats, but it never saw the light of day. As it is, the only compression format widely available in the Macintosh world that is also public domain is that used by StuffIt 1.5.1, an older and less efficient version of the now-proprietary StuffIt 3.0 format.
Most people on the Internet compress Macintosh files in one of three ways: StuffIt, Compact Pro, or as a self-extracting archive. In addition, there are at least three or four other programs that can compress files, but few people ever use them for files posted on the Internet, other than for self-extracting archives.
Perhaps the most popular Macintosh compression format on the nets today is StuffIt 3.0, which is used by a family of programs -- some free (StuffIt Expander), some shareware (StuffIt Lite), and some commercial (StuffIt Deluxe) -- from Aladdin Systems. StuffIt files always have the .sit extension. The only confusion here is that the StuffIt file format has gone through three main incarnations: 1.5.1, 2.0, and 3.0. The latest versions of all the StuffIt tools can read all of those formats, but not surprisingly, StuffIt 2.0-class tools can read only files created in 2.0 or 1.5.1, and StuffIt 1.5.1 can read only files in its specific format.
Note: Although the StuffIt file format is version 3.0, the latest version of the programs is 3.5 -- the file format didn't change when Aladdin revised the programs.
This limitation leads to the common problem on the nets whereby people download a file in StuffIt 3.0 format assuming they can expand it with a StuffIt 2.0-class program because of the .sit extension. Unfortunately, because all three file formats use the .sit extension, the extension provides no useful indication, and StuffIt 2.0 spits up all over a StuffIt 3.0 file. The simple solution to this problem and most other compression problems) is -- and listen carefully -- StuffIt Expander.
StuffIt Expander can expand any StuffIt format, it can expand Compact Pro archives, and as an added bonus it can debinhex files as well. It slices, it dices, and... let me just say that no one should be without StuffIt Expander. That's why I put it on the ISKM disk. Thanks are due to Aladdin Systems for making such a useful tool available for free. You can find the latest versions of StuffIt Expander and StuffIt Lite online in the directory:
ftp://ftp.tidbits.com/pub/tidbits/tisk/util/
There's actually a caveat to StuffIt Expander being free. Aladdin Systems has released a shareware program called DropStuff with Expander Enhancer which, when you pay your shareware fee, gives StuffIt Expander the capability to expand basically all the file formats that the full StuffIt Deluxe can expand through its translators. In addition, you can stuff files quickly by merely dropping them on DropStuff, so it's a doubly useful program. I strongly recommend you register DropStuff with Expander Enhancer if you intend to work with many different file types from the Internet. Another way to get the same functionality is to buy one of Aladdin's commercial programs, such as StuffIt Deluxe or SITcomm.
Compact Pro, a shareware compression utility from Bill Goodman, is almost as popular as the StuffIt family in the Macintosh world. Functionally, StuffIt and Compact Pro do the same thing -- create a compressed archive of one or more files. In my experience, both utilities do an admirable job, so personal preference and other features may sway you one way or the other.
Compact Pro files are always identified by their .cpt extension. You may see an earlier version of Compact Pro floating around on the nets as well. It's called Compactor and uses the same file format as Compact Pro, so you don't have to worry about which version created a given file. Compactor is just an older version of Compact Pro, but Bill Goodman had to change the name for legal reasons. You can find Compact Pro in:
ftp://ftp.tidbits.com/pub/tidbits/tisk/util/
What if you want to send a compressed file or files to a friend who you know has no compression utilities at all? Then you use a self-extracting archive, which is hard to describe further than the name already does. Most compression programs on the market can create self-extracting archives by compressing the file and then attaching a stub, or small expansion program, to the compressed file. The self-extracting archive looks like an application to the user, and if you double-click on a self-extracting archive, it launches and expands the file contained within it. Internet file sites prefer not to have many files, particularly small ones, compressed in self-extracting archives because the stubs are a waste of space for most people on the nets, who already have utilities to expand compressed files.
You can always identify self-extracting archives by the .sea extension. You can tell by the icon which compression program created any given self-extracting archive, but on the whole it makes no difference. The only exceptions to this naming scheme are self-extracting archives created by Alysis's SuperDisk program, which automatically appends a .x to the end of its self-extracting archives. You don't see many, if any, of these.
Unix has a built-in compression program called, in an uncharacteristically straightforward fashion for Unix, Compress. Compress creates files with the .Z extension (note the capital Z -- it makes a difference). Although you don't see files with that extension too often in Macintosh file sites, plenty of them exist on the rest of the net. Both StuffIt and a program called MacCompress (available in the URL below) can expand these files, should you need to do so.
ftp://ftp.tidbits.com/pub/tidbits/tisk/util/
Note: Incidentally, MacCompress was written by Lloyd Chambers, who later went on to write DiskDoubler and AutoDoubler, starting the transparent compression market in the Macintosh world.
As far as I know, Compress works only on a single file, but you often want to put more than one file in an archive. All of the Mac compression programs both archive and compress in a single step. Under Unix, however, you need to perform the archiving step before you compress the file (and of course, if you want to mail it to someone, then you need to uuencode it). A program called Tar (which stands for Tape archive) archives under Unix; files archived with Tar get a .tar extension. If you archive a bunch of files with Tar, then shrink them with Compress, and then uuencode the compressed file to send to someone, the resulting filename may end with .tar.Z.uue to indicate what you've done to it and in what order.
Recently, a new format, called gzip, has started to take over the Unix world. It's marked by the .z or .gz extension. Gzip is the free GNU version of ZIP, a popular PC compression format. A Macintosh version, called MacGzip, recently appeared to decode these files. You can find it online in:
ftp://ftp.tidbits.com/pub/tidbits/tisk/util/
Note: What's GNU? Not much, what's GNU with you? Sorry, but my editor made me put that in. GNU stands for the paradoxical "GNU's Not Unix" and is a project to create a fully functional version of Unix that can you are free to do with as you please.
You may run across several other compression formats in your net travels. Not many people use these formats for files distributed to the world, but a few do, so the rest of us have to stay on our toes. DiskDoubler, from Symantec, can create "combined files" that generally have a .dd extension. Symantec makes a free DDExpandOnly application available for people who don't own DiskDoubler. Alysis's SuperDisk can create its own .x self-extracting archives. Now Compress, from Now Software, can make stand-alone and self-extracting archives. If you run into one of the stand-alone files, look for the free Expand Now application from Now Software in:
ftp://ftp.tidbits.com/pub/tidbits/tisk/util/
Note: Don't be confused about DiskDoubler's company, because it changed since the first edition of this book. Lloyd Chambers wrote DiskDoubler for his company, Salient Software, which was then purchased by Fifth Generation Systems. Then, Symantec bought Fifth Generation Systems, getting DiskDoubler and the other Salient utilities in the bargain. It's kind of an industry food chain...
If you run across a very old archive, it might have a .pit extension, which means that it was created by an old program called PackIt (which I haven't seen in years). Don't bother looking for PackIt, and if you find it, don't create any files with it because it's a dead format. Several of the compression utilities (I don't have a PackIt file to even test this) claim to be able to expand PackIt files, but frankly, no one cares much anymore.
Unfortunately, at some point you are bound to run into files compressed with DOS programs. In most cases these files are text files that you can easily read on a Mac as long as you can expand them. The most common DOS format is the ZIP format, which uses the .zip extension. Several shareware tools such as ZipIt and UnZip exist for unzipping these files, and StuffIt Deluxe also includes a translator for unzipping files. You can find these utilities in:
ftp://ftp.tidbits.com/pub/tidbits/tisk/util/
Almost totally unseen these days is the .arc extension, which was a common format several years ago, so there were several DOS programs that created and expanded .ARC files. Once again, if you see one of these extensions on the Mac, try using StuffIt's translators.
You may want to keep in mind a number of other file type issues, relating both to formatting text files for different systems and to graphics files that you find on the Internet.
Text files are universally indicated by the .txt extension, and after that, the main thing you have watch for is the end-of-line character.
Unix expects the end-of-line character to be a linefeed (LF, or ASCII character 10), which usually shows up on the Mac as a little box because it's a nonprinting character in most fonts. The Mac ends its lines with carriage returns (CR, or ASCII character 13), and to further confuse the issue, DOS machines straddle the fence and use a carriage return and linefeed combination (CR/LF).
Because the Internet is nondenominational when it comes to computer religion (that is, the Internet as a whole; almost every individual is rabid about his or her choice of computer platform), most communication programs are good about making sure to put any outgoing text into a format that other platforms can read. Most programs also attempt to read in text and display it correctly no matter what machine originally formatted it. Unfortunately, as hard as these programs may try, they often fail, so you must pay attention to what sort of text you send out and retrieve -- via email, FTP, Gopher, or whatnot.
When you're sending files from a Mac, the main thing to remember is to break the lines before 80 characters. "Eighty characters," you say. "How the heck am I supposed to figure out how many characters are on a line without counting them all? After all, the Mac has superior proportionally spaced fonts. Humph!"
Yeah, well, forget about those fonts when you're dealing with the Internet. You can't guarantee that anyone reading what you write even has those fonts, so stick to a monospaced font such as Monaco or Courier. I personally recommend Monaco 9 point if your eyes don't mind. Then, I recommend setting your word processor's ruler (if that's where you're typing the file) to approximately 6.25 inches. That way, you have around 64 characters per line, give or take a few. Finally, if you're using a sophisticated word processor such as Nisus Writer, you can run a macro that replaces spaces at the end of each line with hard returns. If you don't use Nisus Writer, you can probably find an option that enables you to Save As Text, and that inserts returns at the end of each line in the process.
Note: There are also several utilities, including one called Add/Strip, that add returns for you. You can find Add/Strip in the usual place:
ftp://ftp.tidbits.com/pub/tidbits/tisk/util/
After your lines have hard returns (carriage returns on the Mac) at the end, you usually can send a file properly, because most communications programs can handle replacing carriage returns with linefeeds or perhaps simply adding linefeeds. If you don't add returns and someone tries to read your text file under DOS or Unix, the file may or may not display correctly. There's no telling, depending on that person's individual circumstances, but you usually hear about it if you screw up. Test with something short if you're unsure whether you can send and receive text files properly.
Often, the Internet client program automatically strips and replaces linefeeds with carriage returns on files coming in from the Internet. If that doesn't happen, you either can use Add/Strip or one of its compatriots, or just run a Find and Replace in your word processor.
Note: If you search for the linefeed (by copying the little box from the document into the Find field in your word processor) and replace it with the carriage return, the file still has hard returns at the end of every line. Instead, try this: Search for two linefeeds; replace them with some special character that doesn't otherwise exist in the document (I usually use Option-8, the bullet); then search for one linefeed and replace it with a space; finally, replace your bullets with carriage returns. As a result, you get nicely wrapped text (assuming of course, that there were blank lines separating paragraphs in the original file).
The other reason to view files from the Internet in a monospaced font with lines delimited by hard returns is that people on the Internet can be incredibly creative with ASCII tables and charts. Using only the standard characters you see on your keyboard, these people manage to create some extremely complex tables and graphics. I can't say they are works of art, but I'm often impressed. If you wrap the lines and view in a proportionally spaced font, those ASCII tables and graphics look like textual garbage.
One other note on text formatting on the Internet. Ian Feldman, with megabytes of comments from me and several others, has defined a "structure-enhanced text" format specifically for electronic periodicals. Files encoded in setext format should have the .etx extension. TidBITS was the first publication to use setext, but more are switching to it every day. Setext has the advantage of being eminently readable online, where it conforms to the least common denominator of Internet machines (less than 70-character-long lines, only the standard character set, and so on), but special front-end programs enable you to browse a setext file and add structure, navigational capabilities, and enhanced display features such as fonts and styles. The idea is to profit from the best of both worlds, the online text-based platforms and the graphically oriented client machines many of us use.
The trick setext employs to remain so unobtrusive online while retaining a format that special browsers can read is making the code implicit in the text and using accepted online styles when possible (see figure 10.4). The title of a setext file, for instance, is a line of characters followed by another line of the exact same number of equal signs, effectively forming a double underline. Subheads are similar, but they are followed by lines of dashes, forming a single underline. Words that should be bold when decoded are sandwiched by asterisk pairs like **this**, and words that should be underlined are sandwiched by underscores like _this_.
Figure 10.4: Example of setext.
It's best to read a setext in a browser such as Akif Eyler's Easy View (primarily a Macintosh browser, although versions are available for Unix and Windows). Easy View can replace the awkward underscores and asterisks with bold and underline styles and can break up a setext into its sections, displaying each subhead separately. But if you can't or don't want to use a program such as Easy View, any program that can display a text file will suffice. You can find the latest version of Easy View in:
ftp://ftp.tidbits.com/pub/tidbits/tisk/util/
I don't want to say much about HTML here, since although it's a text file format that you may run into on the Internet, I plan to provide a short tutorial on the basics of HTML so you can create your own Web pages. So, I want to hold off on talking about HTML until chapter 26, "How to HTML."
For a long time, graphics files weren't commonly posted on the Internet except for use by users of a specific machine, because Macs were not able to read PC graphic file formats and vice-versa. Now, however, you can view some common formats on multiple platforms.
First among these formats is GIF, which stands for Graphics Interchange Format. GIF was originally created by CompuServe. GIF files almost always have the extension .gif. GIF files are popular on the Internet because the file format is internally compressed, although it can show only 256 colors. When you open a GIF file in a program such as Giffer or GraphicConverter, the program expands the GIF file before displaying it.
Note: It seems that almost no one can agree on how to pronounce GIF, either with a hard G sound or with a J sound. Take your pick; I won't argue with you either way.
With the rise of the World Wide Web, two other features of GIF files have become important -- interlacing and transparency.
If you save a GIF file in interlaced format (an option in the shareware GIFConverter for example), some Web browsers can bring in the image gradually rather than all at once. In the current version of MacWeb, the image fades in line by line, with every other line or so being drawn, then the rest of them appearing on subsequent passes. In Netscape, the image appears crude and blocky and gradually becomes more detailed. Interlaced GIFs are useful because the user can stop the image loading or move on if it's a large but uninteresting image. I personally feel that interlaced GIFs should not be used for text-heavy graphics or for what are called image maps on the Web -- pictures that have different hot spots for clicking on. The text-heavy images are disconcertingly hard to read as they come in, and the image maps don't work until the entire image has appeared, which can be confusing.
The transparency feature in GIFs also proves useful on the Web. You can't have nonrectangular graphics on the Web, but you can set one color as "transparent," which means that the Web browser will interpret that color as being the same as the color of the browser's background. This enables seemingly nonrectangular graphics and makes using graphics on Web pages more flexible. A little application from Aaron Giles called Transparency enables you to set a transparent color in GIF images. These and other graphics utilities are in:
ftp://ftp.tidbits.com/pub/tidbits/tisk/util/
The second type of file format you may see is JPEG, which stands for Joint Photographic Experts Group. JPEG files, which are generally marked by the .jpeg or .jpg extension, use a different form of compression than GIF. JPEG file compression reduces the image size to as much as one-twentieth of the original size, but also reduces the quality slightly because it actually throws out parts of the file that you generally can't see. You can view JPEG files (among other formats) with JPEGView from Aaron Giles, which is available in:
ftp://ftp.tidbits.com/pub/tidbits/tisk/util/
JPEG files have become more popular on the Internet now that Netscape and the Web browser in TCP/Connect II 2.1.1 can display JPEG images inline, that is, without running a program such as JPEGView.
Why would you want to use one format over the other? JPEG images can have more than 256 colors in them and are thus better for photographic images. GIFs tend to be better for graphics created on the Mac, especially those with only a few colors. And of course, not all Web browsers can display JPEG images inline yet.
With the advent of the World Wide Web, sound and video files have become far more common on the Internet, although they're so large that most people using a modem won't want to spend the hours required to download a short sound or video clip. But if you have either a fast connection or patience, there are several file formats that you should be aware of.
Sounds come primarily in the Ulaw format. Files in this format have the .au extension. I know very little about the Ulaw format except that there are two programs on the Mac capable of playing it, UlawPlay and SoundMachine, both written by Rod Kennedy. Both are free and seem to work fine, although SoundMachine has a far more sophisticated interface. It wouldn't take much -- UlawPlay merely accepts a file dropped on it, launches, plays the file, and quits. You can find both in:
ftp://ftp.tidbits.com/pub/tidbits/tisk/util
There are two video formats that you should know about, MPEG and QuickTime. MPEG stands for Motion Picture Experts Group. It's actually a compression format much like JPEG, although one optimized for compressing video rather than still images. MPEG files generally have the extension .mpeg or .mpg, as you might expect. The only Macintosh program I know of that can play MPEG files is Maynard Handley's free Sparkle. You can find Sparkle on the Internet at:
ftp://ftp.tidbits.com/pub/tidbits/tisk/util
The most common application for playing QuickTime movies is Movie Player (previously called Simple Player), which comes with the QuickTime distribution from Apple. Many other applications, such as Leonard Rosenthol's Popcorn, can play QuickTime movies as well, but Simple Player works sufficiently well for basic QuickTime movies.
Actually, I lied. There is a third format you may seem on occasion, AVI, indicated by a .avi extension. It's a Windows video format, and although there are no Mac programs that can play AVI files, there is one that can convert AVI files to QuickTime movies, called, as you might expect, AVI to QuickTime Converter. It's at the URL below.
There is a quirk about QuickTime movies that may trip up budding Web publishers: Because of the two Macintosh file forks, you can't just upload a QuickTime movie to a Web server. Instead, you must first "flatten" the movie using a utility like the freeware flattenMoov. It's in:
ftp://ftp.tidbits.com/pub/tidbits/tisk/util/
There you have it, a semiexhaustive (I could have gone into the nitty gritty of each file format, but then you'd have fallen asleep on me) discussion of the major file formats you're likely to run into on the Internet and how to deal with them. I think we've had plenty of background material, so let's move on to figuring out how to choose what sort of Internet access you want and from whom to get it.